Carrier Ethernet is evolving to support the needs of the carrier network environment. Carrier Ethernet requires scalable, reliable, and dynamic mechanisms to support operations, administration, and management (OAM) and traffic engineering (TE). Standards have been developed in the Metro Ethernet Forum (MEF), International Telecommunication Union (ITU), Institute of Electrical and Electronics Engineers (IEEE), and the like providing many of these required extensions. Specifically, Connectivity Fault Management (CFM) is an Ethernet standard to provide many common OAM functions associated with underlying network transport for services. For example, CFM is defined in IEEE 802.1ag-2007 IEEE Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management, the contents of which are herein incorporated by reference. Also, OAM functions are also defined in ITU-T G.8013/Y.1731 (July 2011) “OAM functions and mechanisms for Ethernet based networks,” the contents of which are herein incorporated by reference. Further, the MEF also defines Ethernet OAM in various technical specifications, such as MEF 17 (April 2007) “Service OAM Requirements & Framework,” the contents of which are herein incorporated by reference. Variously, CFM enables definition of maintenance domains, their constituent maintenance points, and the managed objects required to create and administer them; definition of relationships between maintenance domains and the services offered by Virtual Local Area Network (VLAN)-aware bridges and provider bridges; description of protocols and procedures used by maintenance points to maintain and diagnose connectivity faults within a maintenance domain; and the like.
Conventionally, in Ethernet Frame Loss Measurement (e.g., Y.1731 ETH-LM), there is a requirement that both a local and remote end of an Ethernet Virtual Circuit (EVC) being monitored collect real-time service data traffic flow metrics at each end. For example, this can include a transmission frame reception counter (TxFCI) counting data frames transmitted toward the peer Maintenance End Point (MEP) and a receiver frame reception counter (RxFCI) counting data frames received from the peer MEP. It may be impractical for device implementations to persistently collect these service traffic flow metrics (i.e., TxFCI and RxFCI counters) associated with all configured EVCs within the network. For example, the device data collection and storage requirements to support this may not be scalable, especially as the number of EVCs within the network increases. To support persistent collection, device implementations require an over abundance of storage (e.g., memory) and processing capacity to be able to actively monitor all EVCs within the Service Provider's network. However, it is rare to have network elements without storage and processing capacity constraints to support persistent capture. Accordingly, support for performance monitoring capability is typically on an “on-demand” basis and/or only for a subset of the EVCs within a Service Provider's network.
With such typical implementations, the Service Provider still needs to perform a management action on both the local and remote peer NE involved in supporting an Ethernet Frame Loss Measurement (ETH-LM) monitored session. As a consequence, a typical device implementation of the ETH-LM protocol may require explicit notification of the EVC to be monitored, so that it can commence collection of the real-time service traffic flow statistics. As a result, when initiating an ETH-LM session, the network operator may need to “touch” (via management actions) both the local and remote device prior to invoking the frame loss measurement. Multiple management actions at the local and remote devices to initiate an ETH-LM session is operationally inefficient and expensive. For example, there may be many EVCs within the network that may require monitoring of Y.1731 ETH-LM, and thus the multiplicative operational expense may be significant.